Using the dotnet interface, is there a proper method of resetting an axis that will guarantee that the axis does not forget the direction it had last moved, thereby maintaining proper backlash is used for the next move if necessary?

sam marrocco | chief technical officer
ringside.cutters.flavor.picnic.moonlink

248 548 2500 w
248 910 3344 c

ringsidecreative.com

<http://ringsidecreative.com/>

 

Hi Sam,

Not sure exactly what you mean by "resetting"?

Normally the Axes are only Enabled after homing so all that matters is consistency.  Consider maintaining a position offset to leave the machine coordinates forever unchanged to avoid any issue.

But when enabling an axis the Axis Variables "Backlash" and "BacklashDirection" direction are set to zero.  "Backlash" is the amount of currently applied backlash correction and is basically zero if the last direction was negative or the BacklashAmount if the last direction was positive.  BacklashDirection is either -1 (direction of motion negative), 0 (direction of motion unknown), +1 (direction of motion positive).

I suppose if you did a small negative move before disable/enable it would keep the backlash unchanged.

Or save/restore the BacklashDirection and Backlash (These variables are not currently exposed to script commands or KMotion or .NET libraries so C Code would e required).

Might be a poor choice of words on my part. Perhaps the correct term would have been "zeroed". I'll describe what I'm seeing....

I've moved (through UI and code) the Y-axis in a negative, then positive direction. At this point I want to set my DRO to be "0.0" (this is what I previously called 'resetting' the axis.

I then move the Y-Axis in the negative direction. But when I perform a "goto 0.0" (where I had previously zero-ed the axis) the axis actually moves to zero + the current backlash amount.

The method I am using to zero my axis is Axis.ZeroAxis(). I seem to recall somewhere that this disables the axis, sets the current position to zero, then re-enables the axis...? Perhaps this is where the backlash direction is being 'forgotten'.

I've duplicated the same effect by setting the axis manually to 0.0 with
Axis.Disable()
Axis.SetCurrentPosition(Counts)
Axis.SetCommandedDest(Counts)
.Enable

...and again, the backlash direction is ignored, pointing to what you suspected when the Axis is enabled again.

Since C isn't an option for this app and there is no way to access the BacklashDirection (via dotnet) is there another way to tell what direction an axis was last moved? Obviously I could try to track it manually but is there something already present in an Axis besides BacklashDirection that is available to dotnet? Perhaps then I could do a "micro-move" in the opposite direction as you suggest.

Or, perhaps, is there a better manner of setting an Axis to a number without having to disable/enable it?

I'd like to formally request the addition of read/writ properties for BacklashDirection and Backlash to the .Net libraries, regardless.
 



sam marrocco | chief technical officer
ringside.cutters.flavor.picnic.moonlink

248 548 2500 w
248 910 3344 c

ringsidecreative.com

 

On 10/27/2015 7:23 PM, TK tk@... [DynoMotion] wrote:

 

Hi Sam,

Not sure exactly what you mean by "resetting"?

Normally the Axes are only Enabled after homing so all that matters is consistency.  Consider maintaining a position offset to leave the machine coordinates forever unchanged to avoid any issue.

But when enabling an axis the Axis Variables "Backlash" and "BacklashDirection" direction are set to zero.  "Backlash" is the amount of currently applied backlash correction and is basically zero if the last direction was negative or the BacklashAmount if the last direction was positive.  BacklashDirection is either -1 (direction of motion negative), 0 (direction of motion unknown), +1 (direction of motion positive).

I suppose if you did a small negative move before disable/enable it would keep the backlash unchanged.

Or save/restore the BacklashDirection and Backlash (These variables are not currently exposed to script commands or KMotion or .NET libraries so C Code would e required).

Might be a poor choice of words on my part. Perhaps the correct term would have been "zeroed". I'll describe what I'm seeing....

I've moved (through UI and code) the Y-axis in a negative, then positive direction. At this point I want to set my DRO to be "0.0" (this is what I previously called 'resetting' the axis.

I then move the Y-Axis in the negative direction. But when I perform a "goto 0.0" (where I had previously zero-ed the axis) the axis actually moves to zero + the current backlash amount.

The method I am using to zero my axis is Axis.ZeroAxis(). I seem to recall somewhere that this disables the axis, sets the current position to zero, then re-enables the axis...? Perhaps this is where the backlash direction is being 'forgotten'.

I've duplicated the same effect by setting the axis manually to 0.0 with
Axis.Disable()
Axis.SetCurrentPosition(Counts)
Axis.SetCommandedDest(Counts)
.Enable

...and again, the backlash direction is ignored, pointing to what you suspected when the Axis is enabled again.

Since C isn't an option for this app and there is no way to access the BacklashDirection (via dotnet) is there another way to tell what direction an axis was last moved? Obviously I could try to track it manually but is there something already present in an Axis besides BacklashDirection that is available to dotnet? Perhaps then I could do a "micro-move" in the opposite direction as you suggest.

Or, perhaps, is there a better manner of setting an Axis to a number without having to disable/enable it?

I'd like to formally request the addition of read/writ properties for BacklashDirection and Backlash to the .Net libraries, regardless.
 



sam marrocco | chief technical officer
ringside.cutters.flavor.picnic.moonlink

248 548 2500 w
248 910 3344 c

ringsidecreative.com

 

Hi Sam,

I think I understand that. Here is a workaround or a way that "Zeroing" is handled in systems like the GCode Interpreter.  In this case the "Machine Coordinates" in KFLOP are setup once after homing and never changed.  This allows soft limits and moving to fixed positions on the machine in a straightforward manner.  If your application wants to "zero" or set a temporary origin at some position then your Application maintains an "Origin Offset".   So the displayed DRO position is then always:

DRO = Machine Coordinate - Offset.

If you are at a specific location and want to "Zero" the origin at that offset then set:

Offset = Machine Coordinate.

If you want to move to some position X relative to the temporary origin move to machine coordinate = X+Offset.   

Does that work for you?

I think I understand what you are suggesting. The bad thing for me is that it requires modifications to every function in the app that does a position change or read. Ugh.

One thing I'm not clear about: If I am using offsets for everything in my display, doesn't that mean that GCode that is run will move to the wrong place once there is an offset? For example:

True location=5.0
Offset is -5 (DRO would show 0.0)
A GCode file says goto 0.
Won't the interpreter send the axis to True 0 and the DRO now show -5?


 

--

sam marrocco | chief technical officer
ringside.cutters.flavor.picnic.moonlink

248 548 2500 w
248 910 3344 c

ringsidecreative.com

 

On 10/28/2015 1:06 AM, TK tk@... [DynoMotion] wrote:

 

Hi Sam,

I think I understand that. Here is a workaround or a way that "Zeroing" is handled in systems like the GCode Interpreter.  In this case the "Machine Coordinates" in KFLOP are setup once after homing and never changed.  This allows soft limits and moving to fixed positions on the machine in a straightforward manner.  If your application wants to "zero" or set a temporary origin at some position then your Application maintains an "Origin Offset".   So the displayed DRO position is then always:

DRO = Machine Coordinate - Offset.

If you are at a specific location and want to "Zero" the origin at that offset then set:

Offset = Machine Coordinate.

If you want to move to some position X relative to the temporary origin move to machine coordinate = X+Offset.   

Does that work for you?

I think I understand what you are suggesting. The bad thing for me is that it requires modifications to every function in the app that does a position change or read. Ugh.

One thing I'm not clear about: If I am using offsets for everything in my display, doesn't that mean that GCode that is run will move to the wrong place once there is an offset? For example:

True location=5.0
Offset is -5 (DRO would show 0.0)
A GCode file says goto 0.
Won't the interpreter send the axis to True 0 and the DRO now show -5?


 

--

sam marrocco | chief technical officer
ringside.cutters.flavor.picnic.moonlink

248 548 2500 w
248 910 3344 c

ringsidecreative.com

 

Hi Sam,

Well if you include the offset in a single low level function to move or read then all your functions shouldn't need to change their functionality.

Actually I didn't realize you were using the GCode Interpreter.  The GCode Interpreter has several offsets to deal with shifting origins (which can also be used to "zero").  It will then include all those offsets automatically in any commanded move commands.  All you will need to do is to set one of those offsets appropriately.  There is basically 3 offsets:

#1 G92 type of global offset
#2 G55... type of local fixture offsets
#3 Tool Offsets

To "Zero" the Interpreter using the global G92 offset you can execute:

G92X0

There is also a matter of units: inches, mm, or degrees.  The Interpreter will handle this as well.

In order to undo all the offsets from the measured machine position to display the DRO properly use the .NET function: 

        public void ConvertAbsoluteToInterpreterCoord(double x, double y, double z, double a, double b, double c,
                        ref double xp, ref double yp, ref double zp, ref double ap, ref double bp, ref double cp)
 
To first read the machine coordinates use:

       public void ReadCurMachinePosition(ref double x, ref double y, ref double z, ref double a, ref double b, ref double c)
 

So I'd have an offset in the application that is used for non g-code operations, and an offset that needs to be incorporated into gcode files and match.

I can't say I'm excited about the possibility of these getting "out of sync" as this seems to be very prone to human error, but I have a feeling that someone is going to tell me that that is "how it's done in the real world", as opposed to the closed world of my shop ;)

Lacking the dotnet methods to read/write the backlash direction/amount, I'm considering writing a pair of standalone executables, in C, that can obtain and write those backlash values. Might these executables be placed into a pair of threads on the KFlop? That part seems possible, but I'm not sure how I would provide/obtain values to/from those running pieces of code on the KFlop via dotnet.

--

sam marrocco | chief technical officer
ringside.cutters.flavor.picnic.moonlink

248 548 2500 w
248 910 3344 c

ringsidecreative.com

 

On 10/28/2015 12:52 PM, TK tk@... [DynoMotion] wrote:

 

Hi Sam,

Well if you include the offset in a single low level function to move or read then all your functions shouldn't need to change their functionality.

Actually I didn't realize you were using the GCode Interpreter.  The GCode Interpreter has several offsets to deal with shifting origins (which can also be used to "zero").  It will then include all those offsets automatically in any commanded move commands.  All you will need to do is to set one of those offsets appropriately.  There is basically 3 offsets:

#1 G92 type of global offset
#2 G55... type of local fixture offsets
#3 Tool Offsets

To "Zero" the Interpreter using the global G92 offset you can execute:

G92X0

There is also a matter of units: inches, mm, or degrees.  The Interpreter will handle this as well.

In order to undo all the offsets from the measured machine position to display the DRO properly use the .NET function: 

        public void ConvertAbsoluteToInterpreterCoord(double x, double y, double z, double a, double b, double c,
                        ref double xp, ref double yp, ref double zp, ref double ap, ref double bp, ref double cp)
 
To first read the machine coordinates use:

       public void ReadCurMachinePosition(ref double x, ref double y, ref double z, ref double a, ref double b, ref double c)
 

So I'd have an offset in the application that is used for non g-code operations, and an offset that needs to be incorporated into gcode files and match.

I can't say I'm excited about the possibility of these getting "out of sync" as this seems to be very prone to human error, but I have a feeling that someone is going to tell me that that is "how it's done in the real world", as opposed to the closed world of my shop ;)

Lacking the dotnet methods to read/write the backlash direction/amount, I'm considering writing a pair of standalone executables, in C, that can obtain and write those backlash values. Might these executables be placed into a pair of threads on the KFlop? That part seems possible, but I'm not sure how I would provide/obtain values to/from those running pieces of code on the KFlop via dotnet.

--

sam marrocco | chief technical officer
ringside.cutters.flavor.picnic.moonlink

248 548 2500 w
248 910 3344 c

ringsidecreative.com

 

Hi Sam,

I don't understand why you would need two different approaches to movement.  Or if so why not use the same offset?

I do have different approaches to movement for various reasons, but I would use the *same* offset; it just seems error prone to me to have to enter an offset into the software application, then enter an offset into a GCode script (that matches the one in the app) every time you select a script. That is why I am trying to avoid the offset method if possible.

Regarding C Programs you might copy the Backlash values from the Axis to persist variables that are accessible from .NET.  Or I don't see why you need them in .NET?  Couldn't KFLOP just save them and restore them locally?

I was thinking of the dotnet code as the "hub" for the reading/writing of the variables since that's where it is determined that it is time to do so by a Reset/Axis Enable, but it isn't required that it happen in the dotnet code.

As I understand what you described, my problem is that when an axis is enabled, it forgets the backlash direction value. So ideally for my existing code I would do the equivalent of:

Move axis
In anticipation of a resetting of axis value:
  Get backlash direction and value from KFLOP and store somewhere.
  Reset to new value (triggering an axis enable & clearing the backlash values in the KFLOP).
  Get previous backlash direction and value from where it was stored and restore it to the KFLOP.
Move axis (now correctly because backlash direction and amount were maintained from what they were before the reset).

Are you suggesting a method of "triggering" the KFLOP to do the write and/or read of those values? I suppose I was thinking of the KFLOP threads as more of small loops of code that were self-contained than as something that could be run externally at a given time when triggered by the dot net application. Is this what you mean?


sam marrocco | chief technical officer
ringside.cutters.flavor.picnic.moonlink

248 548 2500 w
248 910 3344 c

ringsidecreative.com

 

On 10/29/2015 7:21 PM, TK tk@... [DynoMotion] wrote:

 

Hi Sam,

I don't understand why you would need two different approaches to movement.  Or if so why not use the same offset?

I do have different approaches to movement for various reasons, but I would use the *same* offset; it just seems error prone to me to have to enter an offset into the software application, then enter an offset into a GCode script (that matches the one in the app) every time you select a script. That is why I am trying to avoid the offset method if possible.

Regarding C Programs you might copy the Backlash values from the Axis to persist variables that are accessible from .NET.  Or I don't see why you need them in .NET?  Couldn't KFLOP just save them and restore them locally?

I was thinking of the dotnet code as the "hub" for the reading/writing of the variables since that's where it is determined that it is time to do so by a Reset/Axis Enable, but it isn't required that it happen in the dotnet code.

As I understand what you described, my problem is that when an axis is enabled, it forgets the backlash direction value. So ideally for my existing code I would do the equivalent of:

Move axis
In anticipation of a resetting of axis value:
  Get backlash direction and value from KFLOP and store somewhere.
  Reset to new value (triggering an axis enable & clearing the backlash values in the KFLOP).
  Get previous backlash direction and value from where it was stored and restore it to the KFLOP.
Move axis (now correctly because backlash direction and amount were maintained from what they were before the reset).

Are you suggesting a method of "triggering" the KFLOP to do the write and/or read of those values? I suppose I was thinking of the KFLOP threads as more of small loops of code that were self-contained than as something that could be run externally at a given time when triggered by the dot net application. Is this what you mean?


sam marrocco | chief technical officer
ringside.cutters.flavor.picnic.moonlink

248 548 2500 w
248 910 3344 c

ringsidecreative.com

 

Hi Sam,

It would be helpful to have a better understanding of what you are trying to do.  But normally the Offset to move the origin somewhere would not be in the GCode and would not need to by typed in by anybody.  It would be set by pushing the "Zero" button on the KMotionCNC Screen or doing something similar from your App.

Your saving/restoring of the backlash state is something like I was thinking.  You might use the 200 global persist variables to save any data that you need to share between threads or from one execution to another.   See the description in the wiki here:
http://www.dynomotion.com/wiki/index.php?title=KFLOP_C_Programs#Global_Persist_Variables

I'm going to try the saving/restoring idea with the global persist variables. Will let you know how that works, thanks!

--

sam marrocco | chief technical officer
ringside.cutters.flavor.picnic.moonlink

248 548 2500 w
248 910 3344 c

ringsidecreative.com

 

I have implemented the global persist variables and some KFlop CCode to temporarily store/recall the backlash values. Although I have not tested the app on a mill yet, it appears to solve the issue of the backlash values being cleared upon axis enables. Here is basically what I am doing:

I have two C apps, GetBacklash.c and PutBacklash.c.

The operations that I'm aware of that perform an Axis.Enable include Axis.ZeroAxis(), and of course, Axis.Enable(). Before running either of these functions I run GetBacklash.c in a thread on the KFlop and after the function I run PutBacklash.

The *basic* code is as such:

//------------------------------------------------------------------------------------------------------------------------
GetBacklash.c

#define GPV__AXIS_0_BACKLASH 0
#define GPV__AXIS_0_BACKLASHDIRECTION 1

float Axis0_Backlash;
float Axis0_BacklashDirection;

// Gets the backlash values from the KFlop axis
Axis0_Backlash=ch0->Backlash;
Axis0_BacklashDirection=ch0->BacklashDirection;

// Stores the backlash values in a global persist variable for later use
persist.UserData[GPV__AXIS_0_BACKLASH] = *(int *) & Axis0_Backlash;
persist.UserData[GPV__AXIS_0_BACKLASHDIRECTION] = *(int *) & Axis0_BacklashDirection;
//-----------------------------------------------------------------------------------------------------------------------

PutBacklash.c

//Read the global persistent variables:
Axis0_Backlash = *(float *) &persist.UserData[GPV__AXIS_0_BACKLASH];
Axis0_BacklashDirection = *(float *) &persist.UserData[GPV__AXIS_0_BACKLASHDIRECTION];

// Place the backlash values back into the KFlop axis:
ch0->Backlash=Axis0_Backlash;
ch0->BacklashDirection=Axis0_BacklashDirection;
//-----------------------------------------------------------------------------------------------------------------------


The addition of the global persist variables (and the user variables) is a nice feature I had been unaware of until this dialog. Very handy for trading values between running threads. Not that it is needed for this, but is there a way to get to those variables via dotnet? If so, it is a handy way of accessing values returned from C Code on the KFlop that is not yet accessible to the dotnet libraries.


--

sam marrocco | chief technical officer
ringside.cutters.flavor.picnic.moonlink

248 548 2500 w
248 910 3344 c

ringsidecreative.com

 

Hi Sam,

That looks reasonable to me.  Although ch0->BacklashDirection is actually an integer so the casting for that is unnecessary (but will work correctly).

Ah. Now that I see that it will buzz around in the background processor of my brain until I fix it....thanks!

Speaking of ch0->BacklashDirection, is there a searchable document with a list of all those properties, similiar to the .chm file that exists for the dotnet library? I know this has been brought up before, but the variety of html, pdf, stuff in the assorted help folders, links in the documentation presented in the web pages is difficult to easily search. It seems you might be headed for more unified documentation with the wiki in the future.

--

sam marrocco | chief technical officer
ringside.cutters.flavor.picnic.moonlink

248 548 2500 w
248 910 3344 c

ringsidecreative.com

Hi Sam,

From the wiki:
http://www.dynomotion.com/wiki/index.php?title=KFLOP_C_Programs#Simplest_C_Program

The KMotionDef.h file is included with every installation to define all the functions, variables, structures, and defines available in that Version.  It is located in the DSP_KFLOP subdirectory of the installation.  Open it with the KMotion.exe C Programs Screen to see what's available.

Regards
TK

Quoting "'Marrocco, Sam' SMarrocco@... [DynoMotion]" <DynoMotion@yahoogroups.com>:

 

On 11/2/2015 11:32 AM, TK tk@... [DynoMotion] wrote:

 

Hi Sam,

That looks reasonable to me.  Although ch0->BacklashDirection is actually an integer so the casting for that is unnecessary (but will work correctly).

Ah. Now that I see that it will buzz around in the background processor of my brain until I fix it....thanks!

Speaking of ch0->BacklashDirection, is there a searchable document with a list of all those properties, similiar to the .chm file that exists for the dotnet library? I know this has been brought up before, but the variety of html, pdf, stuff in the assorted help folders, links in the documentation presented in the web pages is difficult to easily search. It seems you might be headed for more unified documentation with the wiki in the future.

--

sam marrocco | chief technical officer
ringside.cutters.flavor.picnic.moonlink

248 548 2500 w
248 910 3344 c

ringsidecreative.com